Cloudflare Zero TrustのDevice postureチェック機能を使用してより詳細な条件でのアクセス制御を行ってみた

Cloudflare Zero TrustのDevice postureチェック機能を使用してより詳細な条件でのアクセス制御を行ってみた

どうもさいちゃんです。今回はCloudflare Zero TrustのDevice postureチェック機能を使用してデバイスの状態に基づいたアクセス制御をする方法についてご紹介します。
Clock Icon2023.08.31

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

先日、「Cloudflare Zero Trustで確認できるログについてまとめてみた」というブログで、Cloudflare Zero Tursutのログについてご紹介したのですが、その中にDevice postureチェックのログもありました。今回はこのDevice postureを設定しポリシーを作成する方法についてご紹介します。

Device postureとは

ゼロトラストを実現するためには、リソースへのアクセスをすべて信用せず、アクセスのたびにその正当性をを検証するために、認証をしっかり行っていくことが重要になってきます。では、ユーザーの正当性は何を持って判断するのでしょう?

認証の方法として、もっとも一般的なのはID/パスワードによるものだと思います。しかし、ゼロトラストではこれだけでは不十分なことが多いです。なりすましを防止するための多要素認証等と組み合わせていく必要があります。  

そして、もう一つ重要なのが今回ご紹介するDevice postureです。Device postureは直訳すると、デバイスの状態となります。デバイスの状態をチェックし、組織の定めた基準をクリアした安全だと判断された端末のみの接続を許可するというのがDevice postureの考え方です。
例えば、デバイスにアンチウィルスソフトがインストールされているか、組織で管理しているデバイスであるか、OSが最新の状態であるか、といった観点でデバイスの状態をチェックします。

いくら厳密な認証を行ったとしてもデバイス自体に脆弱性があっては、本当の意味で安全とは言えません。厳密な認証とDevice postureのチェックを組み合わせて行うことで、より細かなアクセス制御が可能になります。ゼロトラストを実現しようと考えている方はぜひ使っていただきたい機能の一つです。

Cloudflare Zero TrustにもDevice posture機能があります。今回はこの機能についてご紹介していきます。

Cloudflareで確認できるDevice posture

Device postureチェックを有効にし、ポリシーを構成することでより細かなアクセス制御をすることが可能です。

Device postureを使用することが出来るのは、アプリケーションへのアクセスを制御するアクセスポリシーと、エンドポイントからのネットワークトラフィックを制御するネットワークトポリシー、HTTP及びHTTPSリクエストを制御するHTTPポリシーの3つです。

また、Cloudflareの提供するDevice postureのチェック項目は大きく3つの種類があります。それぞれについてどんなことが確認できるのか少し詳しくご紹介していきます。

WARP client checks

Cloudflare WARPクライアントによって行われるチェックです。こちらのチェックを行うためには、前提条件として、WARPクライアントが、Gateway with WARPモードで端末に展開されている必要があります。ここでチェックできることは、以下の通りです。

  • Application check - 特定のアプリケーションがデバイス上で実行されているかどうかを確認することが出来ます。
  • Carbon Black - デバイス上でVMware社が提供するEDR製品のCarbon Blackが動いているかどうかを確認することが出来ます。
  • Device serial - デバイスのシリアルナンバーがあらかじめ用意されたリストに登録されているか否かを確認します。組織が管理している端末からのアクセスのみを許可させたい場合などに有効です。
  • Device UUID - デバイスにUUIDを割り当て、リストを作成し、そのリストに基づいたポリシー作成を可能にします。シリアルナンバーと同じく、組織が管理している端末からのアクセスのみを許可させたいような場合に有効です。
  • Disk encryption - すべてのボリューム、もしくは特定のボリューム(複数選択可能)のディスクの暗号化がされているかどうかを確認することが可能です。
  • Domain joined - ユーザーが特定のWindows Active Directoryドメインのメンバーであるか否かを確認できます。
  • File check - 特定のファイルが存在しているかどうかをチェックすることが出来ます。フィンガープリントやSHA-256の確認も出来るようになっているので、ファイルが改ざんされていないかの確認も可能です。
  • Firewall - デバイス上でファイアウォールが有効になっているかを確認します。
  • OS version - OSのバージョンを確認することが出来ます。特定のバージョンを指定し、そのバージョン以降のバージョンはすべてチェックをパスさせる等の設定が可能です。
  • Require WARP - WARPクライアントが実行されているかどうかを確認します。このルールに基づいたアクセスポリシーを設定することで、保護されたリソースへのアクセスをさせる前にWARPが有効になっていて、安全な通信が可能な端末かどうかを確認することが出来ます。
  • Require Gateway - Cloudflare Gatewayの設定によってトラフィックがフィルタリングされている端末かどうかを確認します。このルールに基づいたアクセスポリシーを作成することで、Cloudflare Gatewayで管理している従業員の端末のみからアプリケーションへのアクセスを許可するということが可能になります。
  • SentinelOne - SentinelOneが端末にインストールされているかどうかを確認することが出来ます。

Service-to-service checkes

他のサービスとの統合によってサードパーティーAPIからDevice postureのデータを取得し、そのデータをもとに行われるDevice postureチェックです。 下記に記載のサービスとの統合が可能です。

  • CrowdStrike - CrowdStrikeが算出したゼロトラスト評価のスコアに基づいたポリシー作成が可能です。スコアの低いものは内部アプリケーションにはアクセスさせたくないといったような場合に有効です。
  • Kolide - KolideはOSにインストールすることで、危険な設定を行っているデバイスを特定しリスト化することが可能です。Kolideによってデバイス上で検出された問題の総数に基づいたポリシー作成を行うことが出来ます。
  • Microsoft Endpoint Manager - Microsoft Endpoint Manager(現在はMicrosoft Intune)で設定したコンプライアンスポリシーの情報に基づいたポリシーの作成が可能になります。
  • SentinelOne - SentinelOneによって収集されたデバイス上の脅威の数やデバイスに何らかのウィルスが感染している恐れがあるか否かという情報をもとにポリシーを作成することが出来るようになります。
  • Uptycs - Uptycsが算出したゼロトラストスコアの情報に基づいたポリシーを設定することが可能になります。
  • Workspace ONE - Workspace ONEのコンプライアンスポリシーの情報に基づいたポリシーを作成する事ができるようになります。

Access integration checkes

Cloudflare Access に登録したアプリケーションに対してのみ行うことが出来るDevice postureチェックです。このチェック項目はネットワークポリシーおよびHTTPポリシーには適用できないのでご注意ください。

  • Azure AD - Azure ADの条件付きアクセス機能と統合して、管理対象のデバイスから特定のアプリケーションへの接続を要求できるようになります。
  • Mutual TLS - 相互TLS認証を行うことで、クライアントとサーバー間の通信が安全であることを保証し、IdPにログインしないリクエスト(IoTデバイスなど)でも特定のリソースへのアクセスを可能にします。
  • Taniu - この設定にした場合、Cloudflare AccessはユーザーIDを検証し、ブラウザはアクセス可否を決定する前にTaniumエージェントに接続し、Taniumのルールに基づいてアクセス制御を行います。

このAccess integration checckesではDevice postureの変化を検出するまでに遅延が発生する場合があります。詳しくはこちらをご覧ください。

やってみた

Device postureのチェックと併せたアクセス制御では、例えば、WARPやファイアウォールが有効になっているかを確認し、インストールされているデバイスに関してはある程度の安全性の低いサイトへのアクセスを許容することでユーザーエクスペリエンスを向上させるといったことや、あらかじめ用意しておいた組織が管理するデバイスのシリアルナンバーのリストを作成しておき、そのリストに記載のあるデバイスのみが社内アプリケーションにアクセス出来るようにするといったユースケースが考えられます。

今回はDevice postureチェックの機能を使用して特定のデバイスにのみHTTPフィルタリングを行っていきたいと思います。 上記で説明したようにCloudflare Zero Tursutでは様々なDevice postureのチェックが可能ですが、今回はデバイスのシリアルナンバーの情報に基づいてフィルタリングを行います。

今回実現したいことは以下の通りです。

  • あらかじめ用意されたシリアルナンバーのリストに基づいたHTTPポリシーを作成する
  • シリアルナンバーのリストに記載がある端末のみをexample.comにアクセスできないように制御する

早速やってみます。

シリアルナンバーリストの作成

Cloudflare Zero Tursutでは、アクセスポリシーやゲートウェイポリシーの作成時に参照するURLやホスト名、その他のエントリのリストを作成することが可能です。 今回は前述したように、デバイスのシリアルナンバーのリストを作成し、ゲートウェイポリシー(HTTPポリシー)作成時にポリシーの適用範囲として参照する形になります。

リストの作成方法ですが、CSVファイルをアップロードする方法と手動で作成する方法があります。
今回はリストの量も少ないので手動で作成する方法でリストを作成してみます。

初めに、ダッシュボードからMy Team > List へ移動します。
今回は、手動で作成したいので、Create manual listを選択します。CSVファイルをアップロードしたい場合はここでUpload CSVを選択します。

Listに分かりやすい名前を付けて、リストの形式を選択します。 今回はシリアルナンバーのリストを作成したいので、List nameはserial number listとし、List typeはSerial numberを選択します。 左側のAdd entryに追加したい文字列を入力していきます。

今回は2つのデバイスのシリアルナンバーを記入していきます。入力したらSaveで保存します。 保存されると、リストの一覧に表示されるようになります。

HTTPポリシーの作成

上記で作成したリストを参照してHTTPポリシーを作成します。 Gateway > Firewall policies > HTTP に移動します。

add a policyを選択して、新しいポリシーを作成していきます。 分かりやすい名前がよかったので今回はBlock example.comという名前を付けておきます。

HTTPポリシーはポリシー範囲を指定する論理式とアクションで構成されています。Built an expressionで論理式となる部分を設定していきます。

まずはexample.comをブロックするためにTrafficでexample.comのドメインを指定します。
Device postureのSelectorでPassd Device Posture Checksを選択します。これで、Device postureのチェックを通過する事が出来た端末が適用範囲となります。
この項目は、Failedも選択可能になっているので、Device postureのチェックを通過できなかったものに限ってポリシーを適用したい場合はそちらを選択しましょう。

最後にSelect an actionでアクションを選択します。今回のアクションはBlockです。これでポリシーを保存します。

これでポリシーの設定が完了しました。

動作確認

では、設定がしっかり反映されているか確認してみます。 まずは、検証機のデバイスシリアルナンバーを登録した状態で、example.comにアクセスしてみます。

上記画像のようにブロックされたことが確認できました。 この時、どのルールに基づいてサイトの表示がブロックされたのか、調べたいので表示されたRule IDを確認しておきます。

HTTPポリシーの一覧にはPolicy IDが表示されています。このPolicy IDと先ほどのRule IDを確認すると、どのポリシーに基づいてブロックされたのかが確認可能です。

ここでIDは一致したのですが、念のため、ログも確認しておきます。 Logs > Gateway > HTTPと進み、Block example.comのポリシーで絞り込みをします。

しっかりとポリシーに基づいてブロックされていることが確認できました。 最後にリストから、検証機のシリアルナンバーを削除してどうなるかを試してみます。

再度example.comにアクセスしてみると、問題なくアクセスすることが出来ました。 ※HTTPポリシーはすぐに設定が反映されるのですが、リストの情報反映には体感で2~3分程かかったのでうまくいかない場合は時間をおいてみてください。

最後にPosutreチェックのログを確認してみます。 Logs > Posutreと進みDevice posture logsを確認してみると、先ほど作成したserial number listに関してのログが記録されています。 作成したDevice postureチェックが実行されるとこのログに記録されるようになっていることが分かります。

まとめ

今回はログの見方をまとめた記事で、気になっていたDevice postureチェックについてまとめてみました。
ゼロトラストを実現するためには、エンドポイントのセキュリティ対策やデバイスレベルでのアクセス制御も必要になってくると思います。WARP client checksは、各デバイスへのWARPクライアントのインストールだけで簡単にDevice postureチェックを始めることが出来るのが嬉しいポイントです。こういった機能を活用しながらDevice postureの重要性について理解を深めていくこともゼロトラスト実現には重要だと思います。

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.